今日份 Ferris

看完資料之後，我們可以開始來開發、選擇與評估模型的表現了，所以今天的主題是以 ML 系統設計的角度來看模型開發，依然是 Ferris 日本動漫化系列，本來想畫擬人化的 Ferris 教螃蟹機器人分辨貓狗，但在嘗試 prompt 途中畫出的螃蟹貓實在太可愛了，所以選這張！

模型選擇 6 大心法

要建立一個機器學習模型，第一步就是選擇要建立哪一種模型，但有這麼多的機器學習演算法 (看到這句話的同時還有一大堆正在積極開發中)。
要怎麼挑選模型，就得謹記以下 6 大心法：

1. 避免落入 SoTA 的陷阱
   通常我們在處理機器學習的問題時，總是會一個衝動要使用最先進的模型 (也就是所謂的 State-of-The-Art)。
   確實，許多人認為最佳的解決方案就是這些模型，畢竟如果有更好、更新的，為什麼還要用舊的？
   但事實上，由於研究者通常只會在學術環境中評估模型，因此最先進的模型通常只代表它在某些靜態數據集上比現有模型表現更好 (例如 ImageNet、MS COCO 等)。
   也就是說，最先進的模型不代表它符合產品所需的速度或成本要求，甚至不代表它能在我們的數據上表現得比其它模型更好。
   在解決問題時最重要的是找到能夠解決該問題的解決方案 (有夠饒口哈哈哈)
   總的來說，如果有一個解決方案可以解決我們的問題，並且比最先進的模型更便宜、更簡單，請使用更簡單的解決方案。

2. 從最簡單的模型開始
   注重簡單性的理由如下：

   • 越簡單的模型越容易部署，而越早部署模型就能越快驗證預測 Pipeline 是否與訓練 Pipeline 一致。
   • 從簡單的開始並逐步添加更複雜的組件，可以使我們更容易理解模型並對其進行調整。
   • 最簡單的模型可作為 baseline 與更複雜的模型進行比較。

   注意，最簡單的模型並不等於最不費工的模型，舉例來說，預訓練的 LLaMa 模型很複雜，但它們很容易使用，像是前面我們就使用了 Hugging Face 🤗 的現有模型。
   在這種情況下，使用複雜的解決方案也並無不可，因為已經有足夠的資源幫助我們解決可能遭遇的問題。
   但是，我們仍然可以嘗試更簡單的解決方案，以確保預訓練的大模型確實比其它更簡單的解決方案還要適合。
   畢竟預訓練的模型雖然容易使用，但卻很難改進，而簡單的模型則有很大的改進空間。

3. 避免在選擇模型時引入人為偏差
   事實上，在評估模型時存在很多人為的偏見，舉例來說，評估模型架構涉及到花時間調整超參數來找到該架構的最佳模型，如果負責的工程師對某個架構更有興趣，他可能就會花更多時間對其進行實驗，這可能會導致該架構的性能會比其它模型更好。
   因此在比較不同架構時，必須格外的注重公平性，以消彌人為引入的偏差。

4. 評估現在的良好表現與後來的良好表現
   現在最好的模型並不總是意味著兩個月後的最佳模型。
   舉例來說，Tree base 的模型現在可能在產品該開始沒有很多資料時運行得更好，但兩個月後，我們可能有更多的訓練資料，此時神經網絡可能會表現得更好。
   因此在評估模型時，我們需要考慮它們在不久的將來會有所進步的可能性，以及實現這些進步的難度。

5. 評估取捨
   在選擇模型時，我們需要做出許多取捨。
   因此了解 ML 系統的哪些表現更加重要將有助於我們選擇最合適的模型，以下是一些其他常見的取捨：

   • 準確率 vs. 速度：更複雜的模型通常可以提供更高的準確率，但也需要更長的時間來訓練和做出預測。
   • 訓練資料 vs. 模型複雜度：更複雜的模型通常需要更多的訓練資料才能達到良好的性能。
   • 模型大小 vs. 部署成本：更複雜的模型通常會產生更大的模型檔案，這可能會增加部署成本。
   • 模型可解釋性 vs. 複雜性：更複雜的模型通常更難解釋。

   在選擇模型時，重要的是要考慮您的特定需求和限制，並定義出優先順序，以更好的評估哪些部分該取捨。

6. 了解模型的假設
   統計學家 George Box 在 1976 年說過：“所有模型都是錯誤的，但有些是有用的。”
   現實世界是難以捉摸的複雜，模型只能使用假設來近似。
   了解模型做出哪些假設以及我們的資料是否滿足這些假設，可以幫助我們評估哪個模型最適合。
   例如，獨立同分布 (IID)、高斯分佈等都是常見的假設，如果不確定模型的假設，或者資料不滿足模型的假設。
   我們可能就需要使用另一個模型！

實驗追蹤與版本控制

在模型開發過程中，我們通常需要嘗試許多架構和許多不同的模型才能為您的問題選擇最佳模型。
一些模型可能看起來彼此相似，只在一個超參數上有所不同 (例如一個模型使用 0.003 的學習率，另一個模型使用 0.002 的學習率)，但它們的性能卻大不相同。
追蹤能夠重現實驗及其相關 artifacts 需要的所有一切，能讓我們比較不同的實驗並選擇最符合需求的實驗。

artifacts 是在實驗過程中生成的的文件，例如損失曲線、評估損失圖、日誌或模型在整個訓練過程中的中間結果。

實驗追蹤顧名思義就是追蹤實驗的進度與結果的流程，而版本控制指的則是為了以後重新創造或與其他實驗進行比較而記錄實驗所有細節的過程。

這兩者是密切相關的，許多最初用於實驗追蹤的工具，例如 MLflow 和 Weights & Biases，已經發展到具有版本控制的功能。
而許多最初用於版本控制的工具，例如 DVC，也已經包含了實驗追蹤的功能。

這裡不會深入討論如何進行實驗追蹤與版本控制，但這是模型開發的必要流程，而開發環境應該包含所有可以簡化工程師工作流程的工具，包括版本控制工具。
截至目前為止，市面上還沒有出現一個完美的工具滿足所有 ML 專案所需要的版本控制。
因此一般會混合使用以下工具：

• Git 控制程式碼版本
• DVC 控制資料版本
• Weights & Biases 或 Comet 用於在開發過程中追蹤模型實驗
• MLflow 用於在部署模型時追蹤模型的各個部件。

版本控制對於任何軟體工程專案都很重要，對於 ML 專案更是如此，因為 ML 專案可以更改的內容很多（程式碼、參數、資料本身等)，並且需要追蹤以前執行的細節以供以後重現，所以混用這些工具創造一個流暢的開發流程是很重要的！

評估模型表現

在評估模型時，建立能與之比較的 baseline 是至關重要的一步，以下是常見的建立 baseline 的方法：

• 隨機 baseline - 如果模型只是隨機預測，預期的性能是什麼？
  預測是隨機按照特定分佈生成的，例如在二元分類中，NEGATIVE 佔 90%，POSITIVE 佔 10% 則隨機預測的準確率就可能是 90%。

• 簡單規則 baseline
  忘記機器學習，如果只是根據簡單的規則進行預測，預期的性能會如何？
  例如我們想要建立一個推薦系統來在社群媒體的河道中排序並推送用戶可能喜歡的貼文，以提高用戶觀看貼文的時間，如果單純按照按讚數量排序，用戶會花多少時間？

• 零規則 baseline
  零規則基準是簡單規則 baseline 的一個特例，我們的 baseline 總是預測最常見的類別。
  例如，若想推薦用戶他們可能會點開的影片，最簡單的模型就是推薦他們點開的帳號。

其它方法可以參考前一個系列文的 [Day 11] 建立 Baseline — 開啟機器學習專案的第一步。

建立好可以比較的 baseline 後，我們就可以開始評估模型，除了整體準確率之外，還有一些常見的評估模型的方法：

• 擾動測試：測試模型對各種測試中的噪聲的敏感程度。確保輸入的某些變化不會導致輸出有任何變化。

• 方向測試：確保輸入的某些變化確實會導致輸出可預測的變化。

• 基於切片的評估：將您的模型分成子集，並分別查看您的模型在每個子集上的表現。
  切片評估之所以重要，其中一個原因是辛普森悖論，這是一種在數據的幾個組中出現趨勢，但在組合併時消失或逆轉的現象。
  舉例來說，假設我們有一個簡單的模型來預測學生是否會被大學錄取。
  我們的模型考慮了兩個因素：學生的在學成績和學測成績。我們對所有學生進行了評估，並將他們分為四組：

  • 高在學成績、高學測成績
  • 高在學成績、低學測成績
  • 低在學成績、高學測成績
  • 低在學成績、低學測成績

  我們發現，在四組當中，在學成績高的學生錄取率都比在學成績低的學生高，這似乎很合理。
  但是，當我們將所有四組學生合併時，我們發現，高學測成績的學生的錄取率比低學測成績的學生高。
  這似乎很奇怪，因為我們之前發現，高在學成績的學生比低在學成績的學生更有可能被錄取。
  這就是辛普森悖論。它發生在我們將數據分成子集時，並且每個子集都有不同的趨勢，但這些趨勢在所有子集合併時會消失或逆轉。
  辛普森悖論提醒我們，在評估模型時，重要的是要考慮所有相關因素，並且不要僅僅依賴整體準確率指標。

今天大概就這樣囉，模型開發是一個很大很廣的主題，這裡僅是整理出了一些較常用到的觀念，或許有些地方沒有說明的很完善，歡迎大家在下面留言補充！
附上在思考這篇文章時候的大腦狀態：

而要開發出有效且符合產品需求的模型還是需要實務經驗，也仰賴於與團隊中不同專業的夥伴多方討論，是一門很深的學問，但只要謹記模型選擇 6 大心法，相信大家都可以做出很讚的 ML 產品。
好啦，歡樂的時光過得特別快，又到時候講掰掰，明天我們就來看看 Rust 該怎麼用於模型開發吧！